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ABSTRACT 


This thesis uses systems engineering to create an architecture description for 
Knowledge Management (KM) at the Launchers Division of the Platform and 
Payload Integration Department at the Naval Undersea Warfare Center. The 
Launchers Division stores and shares technical information poorly, resulting in 
inefficiencies and design rework. A formal KM system could improve the 
situation. The architecture description addresses stakeholder needs while using 
KM best practices. This study consists of problem definition, requirements 
development, and an architecture description. The resulting system top-level 
requirements include create, store, analyze, and report submarine launchers 
knowledge across Naval Sea Systems Command (NAVSEA) and the Fleet. The 
resulting architecture description integrates people, processes, and technology. 
The architecture description is recommended for use in developing a more 


detailed system design for the Launchers Division. 
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XIV 


I. INTRODUCTION 


A. BACKGROUND 


Technology and competition have significantly changed knowledge 
management. 
We are living in a world of rapid change driven by globalization, the 
knowledge-based economy coupled by ever-fast develooment of 
information, communication and_ technology. This change, 
however, not only poses some challenges, but also offers 
opportunities for both private and public sectors alike. (Cong & 
Pandya, 2003) 
The opportunities provided by formalized knowledge management are intended 
to improve handling and communication of technical information in the Platform 
and Payload Integration Department at Naval Undersea Warfare Center Division 


Newport. 


Knowledge management has many definitions and means many things to 
different people. The Department of the Navy Chief Information Officer defines 
knowledge management (KM) as the integration of people and processes, 
enabled by technology, to facilitate the exchange of operationally relevant 
information and expertise to increase organizational performance (Wennergren, 
2005). Love, Irani, and Fong (2004) define KM as “sharing and leveraging 
knowledge within an organization and outwards toward customers and 
stakeholders.” There are multiple definitions of KM but each has a similar theme, 
which is sharing and leveraging knowledge to increase understanding. This is 
where knowledge management can help to improve the Platform and Payload 


Integration Department. 


The Naval Undersea Warfare Center (NUWC) Division Newport is a Naval 
Sea Systems Command field activity. NUWC Division Newport employs 2544 
individuals. Seventy-five percent of the workforce is made up of scientists and 
engineers, and the remaining 25% is support personnel. Over 45% of the 


scientists and engineers have advanced degrees (Lefebvre, 2008). NUWC 
1 


performs research, development, test and evaluation, engineering, analysis and 
assessment, and Fleet support to the United States and foreign navies (Lefebvre, 
2008). Its primary customer is the U.S. Navy and is involved in foreign military 
sales. NUWC has eight technical departments, which are involved in support, 
development, or analysis of the systems and programs shown in Figure 1, Figure 
2, and Figure 3. The systems include submarines, surface ships, weapons, and 
unmanned vehicles. NUWC is a Navy Working Capital Fund, which means it 
operates similarly to a privately owned business. It is like a business because it 
is accountable for efficient delivery of products and services, in exchange for 
funding it recieves from sponsoring commands (Lefebvre, 2008). It differs from 
private business because it acts like a nonprofit organization that does not 


compete with private industry. 
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Figure 1. Submarine systems under NUWC responsibility. 


This figure shows all of the systems that NUWC is responsible for. The launchers division 
works on launchers which include the torpedo system, unmanned undersea vehicles, and 
countermeasures. From (Lefebvre, 2008). 
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Figure 2. Surface ship systems under NUWC responsibility. 


This figure shows the areas that NUWC is involved in on surface ships. The launchers 
division works on countermeasures and torpedo tubes. From (Lefebvre, 2008). 
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Figure 3. Future NUWC projects under development. 


This figure shows the development projects that NUWC is working on. The launchers 
division works on advanced payloads, and Unmanned Vehicles. From (Lefebvre, 2008). 
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The Platform and Payload Integration Department is one of the eight 
technical departments at NUWC. The Platform and Payload Integration 
department has 240 employees that perform research, development, test and 
evaluation, engineering, analysis, and Fleet support to the United States and 
foreign navies (Lefebvre, 2008). Its primary role is to develop and support 
submarine launcher systems and integrate payloads into submarine launcher 
systems. The integration role includes insertion of new payloads, weapons and 
vehicles into submarines and surface ships. The payloads, weapons, and 
vehicles include unmanned vehicles, countermeasures, torpedoes, and tactical 
missiles. The department consists of two divisions, which are the Missiles 


Division and the Launchers Division. 


lf implemented correctly, improved KM _ can_ provide’ improved 
organizational performance through the integration of people, processes, and 
technology. It could provide the opportunity to improve the design of future 
systems, improve current systems, and reduce maintenance turnaround times of 
Fleet systems. Implementation of KM has the potential to improve the 


organizational performance of the Launchers Division. 


B. PURPOSE 


The purpose of this thesis is to conduct research and provide 
recommendations for improved knowledge management within the Launchers 
Division of the Payload and Platform Integration Department at the Naval 
Undersea Warfare Center. It not only will support internal needs for the conduct 


of everyday tasking, but will also meet external needs for long-term initiatives. 


There are many Department of the Navy challenges that the Platform and 
Payload Integration Department is undertaking. These challenges support the 
future of undersea warfare and the United States Navy. One of the more 
important priorities of the Navy is reduction of total ownership costs, which “will 
be key components of all programmatic discussions and decisions” (Roughhead, 


2009). The purpose of the reduction of total ownership cost initiative is to reduce 
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the life-cycle costs of Navy Ships as a response to shrinking budgets. Another 
initiative is Support of the “the Ohio Class replacement which will replace the 
Ohio Class Ballistic Missile Submarines” (Government Accountability Office, 
2010). The Ohio Class replacement program is scheduled to “enter the 
technology development phase in the third quarter of 2010” (Government 
Accountability Office, 2010). The Launchers Division provides technical 


expertise, which includes systems knowledge, to support each of the challenges. 


There are also many submarine community needs that can be addressed 
by a KM system. Recent meetings with the submarine community have revealed 
that “there does not appear to be any method to capture and implement lessons 
learned” and there is “lack of money for basic needs or requirements” (Ybarrondo, 
2010). The Fleet also has “requested explanations to better understand the 
engineering standpoint” (Ybarrondo, 2010) in cases where the technical direction 
does not make sense to the end user. There are other instances of the Fleet 
needing increased understanding of technical decisions and products, and 
elimination of redundant problems. Improved system knowledge and 
communication of technical status of systems between the Fleet and Naval Sea 
systems Command (NAVSEA) is needed. 


In order to meet these challenges and needs, the Launchers Division must 
create, communicate and retain launcher system knowledge. The knowledge 
includes documentation of design decisions and operational support for existing 
submarines. Launcher system knowledge in the Launchers Division is 
dependent on personal experience and individual filing systems. No central 
repository exists, resulting in losses of relevant system data. An improved KM 
system is needed to capture system knowledge from all engineering activities, 
ranging from research and development to operational support. An improved KM 
system may enhance the Launchers Division's ability to provide the data to 


reduce the number of life-cycle problems. 


C. BENEFITS OF STUDY 


This study directly benefits the Payload and Platform Integration 
Department and the Navy by _ potentially reducing costs and_ the 
misunderstanding of technical status between organizations. Cost reduction can 
be achieved by elimination of lost technical knowledge and improved system 
maintenance. Technical knowledge is difficult and costly to recreate. The 
architecture description could also serve as a model for other program offices, 
Navy laboratories, DoD organizations, and in-service engineering agents that are 


involved in development, construction, and repair of Naval Vessels. 


The direct benefit of this thesis to the Platform and Payload Integration 
Department and the Navy is due to the potential of the KM system to generate 
significant cost savings through the reduction of redundant efforts. Cost savings 
from the reduction of redundant efforts will allow allocated funding to be used on 
other problems. Resolution of additional issues allows more efficient use of Navy 
resources. The additional resources could be used to improve launcher system 


performance. 


The KM system could also provide lessons learned from similar systems. 
Use of lessons learned has the potential to avoid system design problems and 
improve launcher system personnel performance. Reduction of system design 
problems could reduce the overall cost through elimination of rework, reduction 
of maintenance and system operation issues of future platform and payload 
development. Improved performance of launcher division personnel will have 
direct effects on the life-cycle costs of launcher systems. This could have direct 
benefit to future Virginia Class platforms and the Ohio Class Replacement 
Program. It also could serve as a model for development and implementation of 


other Navy KM systems. 


D. RESEARCH QUESTIONS 


This thesis answers the following questions: 


e What is an improved way to manage technical data ranging from 


design to operational support for the Launchers Division at NUWC? 


© What is the best high-level architecture description for the technical 


KM system? 


E. SCOPE AND METHODOLOGY 


This section describes the scope and methodology for this thesis. The 
scope defines the narrowly focused areas researched and the problem space 


explored. The methodology includes conduct of research. 


1. Scope 


The scope of this project is limited to the Payload and Platform Integration 
Department Launchers Division technical knowledge management. The intent is 
to create an open architecture description that meets the Launcher Division 
needs. The systems architecture description is subject to all of the DoD security 
requirements, primarily the OPNAV 5000 series but will not provide a method for 
implementation of these guidelines. The architecture description supplements 
existing systems from higher tier organizations but does not replace them. The 
architecture description reflects the constraint that the initial solution on which it 
is based will be implemented in the next three years. The development of a 


systems architecture keeps cost in mind but does not provide a cost analysis. 


2. Methodology 


A tailored systems engineering process is applied to resolve the problems 
associated with KM in the Platform and Payload Integration Department. The 
high-level process is shown in Figure 4. This process generated requirements 
that results in a recommended system architecture description that makes use of 
KM best practices. 
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Top Level 


Derived 





























Requirements Requirements 
Stakeholder Architecture 
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Figure 4. Process layout 


This figure shows the three step systems engineering process layout. The steps 
correspond to each of the chapters. 


The Figure 4 process has three distinct sections: problem definition, 
requirements development, and architecture development. The problem 
definition process identifies the problem, performs a detailed situational analysis, 
and performs a review of KM best practices. This process yielded the top-level 
requirements and selection of stakeholders, which are used in the requirements 
development process. The requirements develooment process consisted of a 
functional analysis, requirements generation, and requirements analysis. The 
requirements development process outputs are derived requirements, and a 
functional hierarchy, which are used in the architecture development process. 
The architecture development process consisted of concept generation, concept 
evaluation, and recommended architecture. The output of this process is an 
architecture description. The feedback loop in each of the sections is included, 
because the problem is constantly refined and bounded as the solution is 


developed. Each section corresponds to a chapter in this thesis. 


The process was created to provide the framework for creation of a KM 
architecture. The process is based on implementation of a successful system. 
Chan (2002) concluded that success depends on understanding strategic 


business needs, employee buy in, and a system tailored to user’s needs. 


The system for the Launchers Division was created for meeting the 


stakeholders’ needs as identified in the surveys and observations. The best 
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system is the one that meets or exceeds all of the top-level requirements and is 
better than the other concepts. This thesis answers the best way to implement a 
technical KM system for the Launchers Division by providing an architecture 


description based on the Figure 4 systems engineering process. 


The Figure 4 processes were selected to answer each of the thesis 
questions. The problem definition process provides the criteria for answering the 
thesis questions. The process takes inputs from the stakeholders and combines 
them with KM best practices. This combination provides the criteria for creation 
of the best architecture description. The requirements and architecture 
development are structured processes to translate the criteria generated into the 
architecture description. The architecture meeting the top-level requirements 
makes the system the best architecture description wnen compared to the other 


concepts. 


F. CHAPTER SUMMARY 


The first chapter introduces the KM problem, the benefits of the study, 
research questions, and scope and methodology. It provides an overview of the 
Launchers Division at NUWC and KM. _ The problem is a need to improve the 
documentation and communication of information within NAVSEA and to the 
Fleet. An enhanced KM system could improve the Launchers Division support of 
the Fleet and development of new technologies. The following chapters use 


systems engineering to develop an architecture description. 
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ll. PROBLEM DEFINITION 


A. INTRODUCTION 


Problem definition is the most important step in systems engineering. The 
success or failure of a project depends on it. The problem definition process 
used in this thesis has four phases shown in Figure 5. The phases include 
stakeholder identification and need, situational assessment, KM best practices 
review, and synthesis of results. The feedback loops in Figure 5 are important 
because each of the phases used the information to build on one another. This 
chapter generates top-level requirements that are utilized in the requirements 


development process. 
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Figure 5. Problem Definition Process 


The problem definition process combines stakeholder need identification with a 
situational assessment and best practices review. 


The development of Figure 5 resulted from reviews of Buede (2009), 
Blanchard and Fabrycky (2006), Sage and Armstrong (2000), and Langford 
(2009). The stakeholder identification and need phase identifies stakeholders 


internal and external to Launchers Division, finds their needs, and bounds the 
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problem. The stakeholders and their needs are the outputs. The situational 
assesment evaluates the past, present, and future state of the Launchers 
Division KM to further refine the needs of the stakeholders. The output of the 
situational assessment Is refined stakeholder needs, which results from better 
understanding of the stakholders and their environment. The KM best practices 
review conducts a literature review that provides insight into the knowledge 
management cycle and other successful systems. Its outputs are an 
understanding of the KM cycle and key elements of a KM system. The synthesis 
of results phase takes the inputs from the other three phases creating the top- 


level requirements, system boundaries, and defined stakeholders. 


The feedback loop in Figure 5 is included due to the necessity to 
constantly refine the top-level requirements throughout the SE process. When a 
problem is encountered with the requirements, it can have an effect on the higher 
level and lower level requirements. Problems encountered include changing 
requirements, funding, conflicting requirements, and roadblocks that cannot be 


overcome. 


There are differences between internal stakeholders within the Launchers 
Division and external stakeholders outside of the Launchers Division. Internal to 
the Launchers Division means the NUWC employees who work for the division 
and those who have access to its information systems. These _ include 
government and contractor personnel. External stakeholders are the customers, 
such as NAVSEA headquarters, contractors, and the Fleet that do not have 
access to all of the division's information systems. Access to information differs 


between the internal and external stakeholders. 


B. STAKEHOLDER IDENTIFICATION AND NEED 


stakeholder identification and need is an important part of the SE process. 
Without stakeholders needs there is no problem. The inputs into this section 
were generated from observation and the surveys described in Appendix A. The 


outputs of this section are stakeholder identification and their needs. 
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Identification of stakeholders is a major part of the problem definition 
process. Stakeholder identification is intended to find all of the personnel who 
are going to be involved with development, fielding and disposal of the intended 
architecture description. Feedback from the other phases in the problem 
definition process resulted in the selected stakeholders. The stakeholders 
include Launchers Division management, Launchers Division engineers, selected 
customers, and contractors. The selected customers include Naval Sea Systems 
Command program offices and technical warrant holders, and submarine Fleet 


representatives. 


Once the stakeholders were identified, their needs were analyzed. The 
stakeholder needs were generated from surveys, and the situational assessment. 
Not all of the stakeholders were surveyed. Only the selected stakeholders who 
responded to the request for conduct of the survey participated. Twelve people 
responded to the survey. Results and additional information on the survey are 
presented in Appendix A. Note that there are solution neutral and solution 
specific needs in Appendix A. The primary needs identified are a system to store 
and retrieve data, and improvement of communication between the stakeholders. 
The system should be easy to use, and provide means of archiving design 


decisions and system history. 


The following are primary results of the survey. The ranking of the 


stakeholder needs are based on the frequency of each response. 


1. Provide a searchable database that stores division technical 


documentation. 
2. Provide a usable system. 


3. Facilitate communication of technical knowledge within and outside 


of the Launchers Division. 
4. Provide backup of data. This system should be redundant. 


5, The data generated by the system shall last at least 30 years. 
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The results reported above eliminate solution-specific requirements. These 
include use of Google™ desktop, Microsoft Access®, and Wikipedia®. The 
survey results show varying levels of understanding and experience throughout 


the organization. 


The stakeholder identification and need process also identify system 
boundaries. One of the more important ones is the system is limited to the 
Launchers Division product line. This thesis will not address transfer of 
unclassified documentation from a higher classification system. Transfer of 
information from one system to another is very hard to complete and outside of 


the scope of thesis. 


C. SITUATIONAL ASSESSMENT 


The situational assessment further defines and evaluates the _ initial 
problem identified. It accomplishes this by assessing how the KM system 
operated in the past, how it operates in the present, and the possible future state 
of the Launchers Division projects. The situational assessment methodology is 
based on Sage and Armstrong (2000) and Maier and Rechtin (2000). The data 
for the situational assessment is generated from research on and observation of 


the available systems and stakeholders in action. 


1. Past 


The description and results of internal and external evaluations of the past 
state of the Launchers Division KM are described in this section. The internal 
KM evaluation focuses on the processes and technology in place in the 
Launchers Division. The external evaluations consists of the Missiles division 
and other departments within NUWC. The inputs are the problem, observations, 
and surveys. The output is insight into how NUWC division Newport KM was 


conducted in the past. 


The internal evaluation consists of the Launchers Division KM processes 


and technologies that are used. This evaluation was accomplished through 
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Survey responses and observation of the current system. The survey reveals 
that the Launchers Division KM processes rely on system experts to retain 
documentation and unwritten system knowledge. This process is_ highly 
dependent on the diligence and the willingness of the individual to share, 
document, and archive information. Paper and microfiche files are used to store 
technical data. If the system expert left the department for retirement or a new 
position, Knowledge transfer is dependent on that individual sharing both written 


and unwritten information with new employees. 


The Missiles Division KM system was purchased by NAVAIR from Boeing 
in the early 1990s. It was created to provide a system to support life-cycle 
planning and history of the Tomahawk Missile program. It is called the 
Tomahawk Information System. lt provides many functions including 
configuration and financial management, a data repository, in-service problem 
reporting, and design information. Tomahawk Information System (TOMIS) is 
available to relevant stakeholders using a secure Web site. The stakeholders 


include the Fleet, program office, and contractors (Sujecki, 2010). 


Other departments at NUWC have other systems that are used for 
Knowledge Management. One of the systems, Advanced Interactive 
Management Technology Center (AIMTC), is used for submarine combat 
systems and has existed since the 1990s. Since 2001, AIMTC has provided 
real-time chat with deployed platforms, which was considered by the Fleet to 
provide outstanding support for the submarine fire control systems (lriye, 2004). 
AIMTC also has a data retention capability that allows maximization of data 


collection and retention (lriye, 2004). 


The Platform and Payload Integration Department knowledge 
management in the past and present is division dependent. Each division has its 
own process. The Missiles Division runs a comprehensive KM system for the 


Tomahawk Missile program office at Naval Air Systems Command (NAVAIR), 
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which is their primary sponsor. The Launchers Division does not have a similar 
system in place. Other divisions and departments run other KM systems at 
NUWC Newport. 


2. Present 


The evaluation of the present was conducted to understand how the 
existing system is operating. The evaluation of Launchers Division knowledge 
management consisted of problems faced and existing systems used in the 
division. It included a similar look at external organizations. The outputs of this 


were an understanding of the current and future state of the Launchers Division. 


The current state of the Launchers Division KM system has several 
aspects that are undesirable. The Launchers Division KM system functionality 
today is no different than it was in the past. In addition to the past problems, 
there are Fleet concerns with submarine technical support and data calls for the 
Ohio replacement program. There appears to be a lack of communication 


between the Fleet and the technical community. 


The analysis of the present state included an evaluation of the information 
technology systems that retain technical data. The information systems used to 
provide technical data are described in Table 1. The data presented in Table 1 
was generated by observing available databases and information provided from 
the survey conducted (Appendix A). Each of the systems identified perform a 
function and provide access to the information required for work at the Launchers 
Division. In some cases, these systems are hard to use due to security 


requirements. 
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Table 1. 





Available systems to the Launchers Division 


Provider of hardware and software for the Navy. 
Primary information technology provider for the 
Stakeholders identified in this chapter. Has specific 
software and hardware that are approved for use. If 
one wants to add software it has to be certified. 
Additional storage of data and software for a fee. 
Provides unique software and hardware that are not 
available from NMCI. It is primarily used for design and 
analysis projects. Not all users have access to the 
Network. It has a network storage capability that is 
available to all users for file sharing. 

Provides financial data management. Provides means 
of tracking project milestones and funding allotted to 
tasks. 

Intended to be Navy wide. Provides Project 
Management tools including milestones, earned value 
management etc. NAVSEA is implementing it in 
FY2010 and NUWC in FY2011. 

Provides a link to the technical library and other 
technical _ sites. The technical library provides 
specification data. Published technical reports. It also 
provides links to outside organizations and department 
Microsoft SharePoint sites. 

Provides comprehensive list of ship drawings for all 
classes supported. 

Provides a means of communicating sensitive 
information. It also provides ship drawings and the 
deviations related to them. It provides shipbuilder 
baseline test procedures and the completed/signed test 
procedures. It also contains the document databank 
with the majority of letters that have been written by 
Electric Boat Corporation. 


Provides technical data. It includes links to Joint Fleet 
maintenance manual, Ship Systems Manuals, and 
other types of technical data. It also has engineering 
inputs into problems solved but this function is not 
consistently used. 
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Provides date information, letter serial numbers, and 
titles of letters. It does not have a data repository where 
division letters are retained. It also documents 
communications between the In-service Engineering 
Agent and outside customers 


Provides Classified Processing of Data. Provides 
information on ships and means of communication via 
email. 

Provides a means of file sharing and transfer between 
internal Code 40 employees that have access to the 
network. Recently the network has been disconnected 
due to the partition between NMCI and the Research 
Development Test and Evaluation Network. Many of 
the files it contained are inaccessible or hard to find to 
most users. 

Currently provides technical highlights to be provided to 
leadership. These are entered by Code 40 Users. 
This system is available to Fleet and contractor users. 
lt serves as a means of file transfer. It also provides 
system status and logistics data to external customers. 


The Electronic Liaison Action Request (ELAR) system 
provides in-service requests for technical resolution. It 
allows users to enter technical resolutions into its 
database. 


The tracking sheet is to track incoming technical 
correspondence from the VIRGINIA Class Program 
Office. It provides need dates and basic information on 
the technical correspondence. 


The VIRGINIA Class scanned technical data that is not 
accessible to all users. It includes technical reports, 
answers to technical correspondence, and design 
decisions. 


This includes Information Handling Services, which 
provides specification data. If provides a repository for 
technical reports and other technical data. 
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The NAVSEA technical correspondence database 
provides letters that have been issued by NAVSEA. 
There are many issues with this database. First, it is 
hard to search. Even when the correspondence exists 
it is hard to find. Certain users understand how to use 
it and are somewhat successful in using it. It is not 
accessible to Launchers Division personnel. 

The SUBMEPP homepage provides the Joint Fleet 
Maintenance Manual. SUPMEPP provides other 
technical data. 


Internet-based provider of file sharing and work tasking 
run by Naval Surface Warfare Center and used by 
NAVSEA program offices. It is used by some projects 
but not all projects. Data stored is available for a 
certain amount of time and then is removed when not 
used. Access is by hard and soft key encryption. 

Code 40 database for managing and tracking risks 
related to projects. 





The scope of data provided by the systems in Table 1 Is too large for a 
single system for use by the Launchers Division. This is due to the scope, cost, 
and availability of information. Some of the systems have constantly changing 
information which is produced or maintained by other organizations. Maintaining 
information that is under the cognizance of other organizations is almost 
impossible when the data Is constantly changing and is large in volume. Some of 
the information and the software in these systems provided by other 
organizations is proprietary. In some cases, the government would have to pay 
the contractor for these systems and this Is undesirable due to the cost of the 


data. 


Table 1 shows that the data the Launchers Division works with is similar 
across the life cycle of the products it works on. This includes calculations, 
drawings, drawing changes, manuals, specifications, and _ technical 
correspondence. This shows the data the technical community works on is 


similar and can be standardized. Standardization of data allows designers of 
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new systems to obtain data on systemic problems on previous designs. This 
would make the internal system searchable to find the data that they need to 


improve their technical product. 


AIMTC and TOMIS are continuously evolving to meet customer needs and 
DoD security requirements. TOMIS has about 25 personnel that are working on 
it with a 3—5 million dollar budget annually. TOMIS has over 1100 active users at 
150+ sites. It currently has 38 unique modules and 434 software changes were 
made in FY09 (Sujecki, 2010). Both the AIMTC and TOMIS systems are 
required to be up to date with Navy Security policies, which include two site 


registrations and cryptographic log-on technology. 


Evaluation of the current state of KM provides additional insight into the 
KM systems at NUWC Newport. NUWC Division Newport departments have 
different levels of formality, which they have applied to knowledge management. 
The level of formality varies between division or department, or even work group. 
The Launchers Division at NUWC Newport has no formal process for knowledge 
management, resulting in incomplete information and knowledge about the 
systems it works on. The generation of technical documentation should be 
standardized across the life cycle. Not all technical documentation can be stored 
on one system, and the system will have to rely on outside systems to obtain the 
required data. The system will be more cost effective and up-to-date for the 
Launchers Division if it can rely on outside systems to provide data. Other 
divisions and departments in some cases, have more comprehensive KM 


systems in place. 


2: Desired Future State 


The desired future state provides an evaluation of where the divisions’ 
projects will be in the future. This includes status of current and future programs. 
The programs include the Virginia Class Submarine, Ohio Class Submarine and 
Ohio Replacement Program, existing ISEA programs, and Seawolf and Los 


Angeles Class Submarines. 
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The first Virginia Class Submarine was commissioned in 2004, at a cost of 
approximately 2.8 billion dollars (Little, 2008). It is planned to be a thirty-ship 
class. The life cycle of the Virginia Class is 33 years. The Block Ill Virginia 
Contract builds Virginia Class submarines until 2018 (Little, 2008), and brings the 
total number of submarines to 18. The number and life cycle of the Virginia class 
requires the system shall support Virginia Class submarines and the Launchers 
Division until at least 2050. The construction and total ownership costs are 
continuously being reduced through design and construction improvements. The 
combination of ISEA and design support for Virginia Class will require retention 


of launchers knowledge until 2050. 


The Ohio Class and Ohio class replacement program will require support 
until at least 2030 and beyond. Initial Operating Capability in 2029 of the Ohio 
class replacement program corresponds with the first Ohio class ballistic missile 
submarine being decommissioned (O'Rourke, 2010). The Ohio class submarine 
is the United States Sea Based Nuclear deterrent. Application of technical 
lessons learned may provide the opportunity to reduce costs and improve quality 
(Government Accountability Office, 1994) of the Ohio Replacement Program. 
Lessons learned from Virginia and previous classes are important to prevent 


problems, already encountered on existing and new designs. 


The Los Angeles and Seawolf Class Submarines are in the operational 
support and decommissioning stages of their life cycles. The 62 Los Angeles 
Class Submarines, which entered service between 1976 and 1996, have an 
approximate 33-year life cycle and will be continuously retired from now until 
2030 (O'Rourke, 2009). The Seawolf class consists of three submarines 
commissioned between 1996 and 2005, will also be retired in the 2020—2030 
timeframe (O'Rourke, 2009). Retention of the knowledge gained from support of 
these two classes is important for reduction of costs on current and future 


programs. 


Centralized retention of knowledge is important for future support of 


current and future submarines. It supports the Navy initiatives by providing 
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historical technical data and elimination of redundant efforts. Support of the 
submarine launchers systems will be at least until 2050, which means the 
knowledge generated has to survive until then. This shows that a centralized 


technical KM system is better than a stove-piped KM system. 


D. KM BEST PRACTICES 


The KM best practices phase reviews literature to help define the best 
architecture description for the Launchers Division. The review addresses the 
knowledge management cycle and the key elements of a KM system and forms 
the conceptual basis for the system. The key elements provide the fundamentals 
of a successful system based on literature and benchmarking studies. The 


combination of understanding of both of these provides KM best practices. 


The steps to the knowledge management cycle are knowledge creation, 
sharing, capture and application. The steps in the cycle are shown in Figure 6. 
Knowledge creation is where the product knowledge is generated. Knowledge 
capture is where the knowledge is “translated into objective and transferrable 
knowledge or explicit Knowledge” (Nonaka, 2008). Knowledge sharing is 
socialization through the interested parties. Knowledge application is use of the 
knowledge in the applicable situation. The KM cycle is important to a company 
because “individuals’ personal Knowledge transformed into organizational 


knowledge is valuable to the company as a whole” (Nonaka, 2008). 
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Figure 6. Knowledge Management Cycle. 


The knowledge management cycle shows the continuous cycle of knowledge creation, 
capture, sharing and application. The continuous cycle is intended to build on already 
known information. From Love, Irani, & Fong (2004). 

There are two types of knowledge: tacit and explicit. Explicit information is 
easily written and codified. Tacit information is highly personal and hard to 
formalize, which makes it difficult to communicate (Nonaka, 2008). Tacit 
knowledge is partly technical Know-how, such as the skills of a master craftsman, 
which are informal skills and are hard to replicate (Nonaka, 2008). “It consists of 
mental models, beliefs, and perspectives so ingrained that we take them for 
granted and therefore cannot easily articulate them” (Nonaka, 2008). 
Transformation of tacit to explicit knowledge and back are important parts of the 


knowledge management cycle. 
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The key elements of a KM system are people, processes, and culture, 
with technology being the enabler (Love, Irani, & Fong, 2004). There is a 
perception that information technology software is the most important part of the 
solution. It is not. Eighty percent of KM is people, process, culture, and the other 
20 percent is technology (Liebowitz, 1999). The American Productivity and 
Quality Centers Benchmarking Study (2000) also identified people, process, 
culture, and technology as key factors in a successful KM system. The specific 
factors the benchmarking study identified are the following: senior champion or 
management endorsement, budget, communities of practice, culture, and 
information technology are key to successful implementation of a KM system. 
The American Productivity and Quality Centers Benchmarking Study (2000) is 
based on a survey of 49 companies, 10 of which were identified as having strong 


KM initiatives in place. 


Chan (2002) evaluated the NUWC Submarine Electromagnetic 
department KM practices. The Submarine Electromagnetic department performs 
a similar ISEA role to the Launchers Division. Chan’s work was based on loss of 
tacit knowledge due to employee attrition through workforce retirements. Chan 
(2002) suggested using a systematic approach to the development of a KM 
system through understanding of the organization’s core competencies. One of 
the benefits of KM is it leverages the intellectual capital of the entire organization, 
“instead of working as individuals is the only way to gain a competitive 
advantage” (Chan, 2002). Chan's work provides the following conclusion: 

Firstly, for knowledge management to succeed, an organization 

must articulate its strategic business needs, create a common 

framework for understanding, secure employee buy-in, and 

maintain open communications. Secondly, an optimal knowledge 
management system design must take into account the user's 
perspective since efficient Knowledge flow and knowledge 

transformations depend on people's willing participation. (p. 94) 

The NAVSEA ship design department identified its inability to find 
documentation through a NSWC-funded study (Junod, Read, & Kaistha, 2007). 


The study had clear requirements and provided potential technical solutions. It 
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focused on the knowledge cycle presented in Figure 6 to share, create, and 
apply the knowledge to create innovative surface ship designs. The 
documentation needed to create surface ship designs was difficult to find even 
though it was stored on the network drives, which is a similar situation the 


Launchers Division faces. 


This section provides KM best practices for a successful system. These 
practices include the knowledge management cycle and key success factors for 
a KM system. Understanding of the knowledge management cycle (Figure 6), 
and how knowledge is generated is important for understanding knowledge 
management. The transfer of tacit to explicit knowledge is an important part of 
the Knowledge transfer process. An improved KM system should incorporate key 
factors for success, which include a senior champion or management 
endorsement, budget, communities of practice, culture, and _ information 


technology. A better solution is based on stakeholder inputs. 


E. SYNTHESIS OF RESULTS 


The synthesis of results phase creates the top-level requirements for the 
system. This is done by combining the outputs of the stakeholder identification 
and needs, situational assessment, and KM best practices outputs. Each of the 


outputs is solution-neutral and provides problem definition. 


Each of the assessments in Parts B, C, and D, and the follow-on chapters, 


have led to the top-level requirements. 


O The KM system shall provide a data repository to capture and 
communicate technical knowledge for all aspects of the lifecycle of 


Undersea Launcher Systems from development to disposal. 


O The KM systems implementation shall be based on culture change, 


having a senior champion, incentives for use, and available budget. 


O The KM system shall perform the following functions: — store 


technical data, generate Knowledge, analyze the number of 
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documents input to and output by the system, recognize recurrent 
technical problems, handle classified information, organize, 


retrieve, and report internal and external data. 


7 Data includes letters, calculations, technical data packages, 
calculations, analysis files, drawing files, waivers, departures 
from specification, and deviations, technical manuals, and 
maintenance data. The system shall support at a minimum 
Storage of Microsoft Office documentation, Adobe® PDF 


formats, and viewing file formats (i.e., .jpeg, .tiff). 


The KM _ system shall generate knowledge-based knowledge 


creation cycle (Figure 6). 


The KM system shall be easily searchable by internal and external 
personnel to the Launchers Division. Internal personnel include 
people who are employees of the Launchers Division. External 
personnel include technical warrant holders, program office, and 
Fleet personnel. “Easily searchable” means document lists are 
returned within a minute of query, and the user interface is easy to 


read. 


The data generated shall last 30 years and a means of backing up 


the data shall be included. 


The KM system shall be a system of systems and use data from 
available systems. The processes generated can use legacy 
systems. The system shall not replace outside organizations’ 
systems. These include Table 2 (CITIS, ATIS, ELAR) and other 


systems. 


The KM system shall be available to NAVSEA, the Fleet, and 


contractors. 
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O The KM system shall provide a method of translation of tacit to 


explicit knowledge, and back. 


O The KM system shall comply with all of the DoD information 


security requirements. 


O The KM system shall be able to operate on the Naval Marine Corps 


Intranet. 


Fr: CHAPTER SUMMARY 


The top-level requirements generated in this chapter were analyzed and 
refined into system requirements, which was the first step in generation of the 
systems architecture. The initial stakeholder analysis and situational assessment 
were performed to analyze who the stakeholders are, the past and current state 
of affairs, and a study on the current state of knowledge management. A KM 
best practices review was also conducted. The combination of the three 
processes led to the synthesis of top-level requirements and definition of 


stakeholders. 


The surveys, situational assessment, and literature research indicate that 
a comprehensive technical KM system is better than a stove-piped KM system. 
This allows the life-cycle needs of the Launchers Division to be met. The 
technical documentation needed for the Launchers Division across the life cycle 
is similar from design to operational support, allowing for creation of a 
comprehensive system. The system will be more cost effective, and up-to-date, 
if it relies on already existing external KM systems to provide technical data. KM 
requirements and funding are changing constantly; a system that can change is 
better than a system that cannot change. For the system to have the potential to 


be optimal, or the best, it has to be developed based on stakeholders’ needs. 
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ll. REQUIREMENTS DEVELOPMENT 


A. INTRODUCTION 


The process used in this chapter translates the top-level requirements into 
derived requirements. Figure 7 shows this process. It is broken into two 
sections: functional analysis and requirements generation. The outputs of this 
chapter are derived or detailed requirements and a functional hierarchy. 


Derived 
Requirements > 


Stakeholders Defined Functions 


















Boundary Definition Functional Heirarchy 


Functional 




















Top Level Functional Flow Hierarchy > 
Requirements Block Diagrams 
Feedback 
Figure /. Requirements Development Process 


The development process consists of two steps. The two steps create part of the 
functional architecture and generate requirements. 


The functional analysis has three primary steps: generation of functions, 
creation of a functional hierarchy and functional flow block diagrams. A 
functional analysis is an iterative process of translating requirements into detailed 
design criteria (Blanchard & Fabrycky, 2006). Functions are generated from the 
top-level requirements. “A function is a definite purposeful action that a system 
must accomplish to achieve one of the systems objectives” (Sage & Armstrong, 
2000). The functions are then placed into a functional decomposition. The 
purpose of the functional decomposition is to break the needs into smaller pieces. 
The functional flow block diagrams describe the system and its elements in 
functional terms (Blanchard & Fabrycky, 2006). Each of these analyses help with 


further definition of the problem and generation of requirements. 


The requirements generation process results in the derived requirements 


for the system. It starts with an evaluation of functions followed by creation of a 
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functional hierarchy, functional flow block diagrams, and writing a requirement for 
each of the functions. The requirements are written so they are traceable to the 


higher-level functions and top-level requirements. 


B. FUNCTIONAL ANALYSIS 


Functional analysis includes creation of functions, organizing them into a 
functional hierarchy, and creation of functional flow block diagrams. [Each of 
these steps helps develop the problem. The outputs of this phase are functions, 


functional flow block diagrams, and a functional hierarchy. 


The functions are created by translating the top-level requirements into a 
listing of the actions the system is expected to perform. The first step was to list 
all of the functions the system is to perform within the boundaries and top-level 
requirements identified. An example of an action by the system is to collect data. 
Generation of data represents creation of the data that is used in the systems. 
Additional functions were added with generation of the functional hierarchy and 


the functional flow block diagrams. 


The functions include generate data, collect data, input data, store data, 
analyze data, report data, and share knowledge. The input data function follows 
data collection (described above). It is used to partition data prior to storage to 
ensure that it can be found and it is sent to the correct area for classification. 
The data storage function is to keep the data until it is used. Analyze data 
provides statistics on use and launcher system health status. Data reporting 


provides the data requested by users and reports generated by the system. 


The functions are arranged into a functional hierarchy, which shows the 
system function as a whole. The functional hierarchy with numbering is shown in 
Figure 8. It has two levels and can be decomposed further when the system is 
further defined. The functional hierarchy was also compared to the top-level 
requirements to ensure that it meets their intent. In a of couple cases, the 
hierarchy was modified to ensure the top-level requirements’ intent was met. 
Additional functions were added after the functional flow block diagram was 
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created and the functional hierarchy was developed. The functional hierarchy is 


considered to be the functional architecture by Buede (2009). 











Figure 8. Functional Hierarchy. 


The functional hierarchy further defines the system. It consists of six functions and their 
sub functions. 


Following the creation of the functional hierarchy, a functional flow block 
diagram was created for the system. The system functional flow block diagram is 
shown in Figure 9. It provides a more detailed understanding of the functions 
and the interactions between the functions. The creation of the functional flow 
block diagram results in the addition of knowledge sharing to facilitate the 
transfer of knowledge between individuals and organizations. It also provides an 


overview of how the system functions. 


a ee =. 


Figure 9. Functional Flow Block Diagram 





























The functional flow block diagram shows the continuous flow of information. It provided 
Insight into interactions between the functions of the system. 
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Generation of functions, creation of a functional hierarchy, and the 
functional flow block diagrams allow system requirements generation. The 
functions provide the actions. The functional hierarchy partitions the system into 
smaller parts and allows traceability to the top-level requirements. The functional 
flow block diagrams provide a view of the interactions between the functions. 
Each step of the process results in further definition of the problem and feeds into 


generation of requirements. 


C. REQUIREMENTS GENERATION 


The requirements generation process translates the problem definition, 
top-level requirements, and the functional analysis into more specific system 
requirements. Requirements generation analyzes each function, resulting in 
requirements for each function. Verification and validation steps were added to 
ensure the written requirements were testable. This section also required 
considerable iterations to the current and previous phase for a variety of reasons. 


The output of this phase is a list of system requirements. 


The requirements generation process used is iterative and consists of 
multiple steps. The first step was writing specific requirements for each function. 
Then, the requirements were evaluated to see if they could be verified and 
validated. The requirements were then refined following the addition of the 
verification and validation of the requirements. The use of the process resulted 


in a refined set of requirements. 


Verification and validation of the requirements is important to ensure they 
meet the intent of the individual and system requirements. Verification is to 
ensure the elements of the system meet their individual requirements (Buede, 
2009). Validation ensures that the system meets all requirements specified by 
the customer (Blanchard & Fabrycky, 2006). Verification and validation in this 
section are broken into test, inspection, analysis, and demonstration. Some of 
the requirements had to be modified. For example, the requirement “the data 


shall be searchable” did not define what data. The requirement was rewritten to: 
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all documentation contained within the system (shall be searchable). Other 


requirements were either removed or reworded to make them verifiable. 


The requirements are set up in a table that provides traceability from the 
top-level to the derived requirements. This table includes the tie of the derived 
requirements to the functional hierarchy and top-level requirements. Each of the 
functions in the functional hierarchy has been numbered and_ individual 
requirements are numbered with a “KM” and the number corresponding to the 


functional hierarchy. The requirements matrix is provided in Table 2. 


33 





KM1.0 


KM1.1 


KM1.2 


KM2.0 


KM2.1 


Table 2. Requirements matrix 


Test Inspection Analysis Demonstration 
The system shall be able to generate 
data. Generation of data includes 
facilitation of the Figure 6 knowledge 
cycle. This includes standard templates 
for generation of letters, calculations, and 
drawings. 
The system shall be able to create data. 
This includes standard templates for 
generation of letters, calculations, and 
drawings. 
The system shall be able to assist in 
translation of tacit to explicit data. This 
shall include shadowing of experts to 
understand how the task is completed. 
Followed by translation of the tacit 
knowledge by changing it into a form that 
can be used by others. Other methods 
can be used to accomplish this task. 
The system shall provide the ability to 
input data. This includes data that is 
generated on Naval Marine Corps Intranet 
and external to the Naval Marine Corps 
Intranet. 
The data shall be able to be entered by all | x 
users. Users include Launchers Division 
personnel, NAVSEA headquarters 
employees, and Fleet Personnel with 
access to NMCI. 
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Test Inspection Analysis Demonstration 





KM2.2 The system shall have the ability to sort 
data by system and project. Systems 
include torpedo tube, weapon shipping 
and handling, internal countermeasure 
launcher, external and internal 
countermeasure launchers, trash disposal 
unit, surface vessel torpedo tubes, 
weapon shipping and handling, and 
vertical launch systems. The system shall 
include the ability to sort data by project. 


KM3.0 The system shall provide the ability to 
store data. 
KMs3.1 The system shall store technical 


documentation. Technical documentation 
includes letters, calculations, liaison 
action requests, drawings and can be 
expanded to other documents. 

KM3.2 The data storage capability shall be 
expandable to meet the needs of the 
division. 

KM4.0 The system shall provide the ability to 
analyze data. Analysis includes input and 
output metrics. Analysis includes 
identification of system issues (the second 
part can be a follow on capability) 

KM4.1 The system shall be able to analyze 
launcher system data. This function shall 
be performed by launchers personnel or a 
software program. 

KM4.2 The system shall provide input and output 
metrics. This is the number and size of 
documents handled by this system. 

KM5.0 The system shall provide the ability to 
report data. This includes providing data 
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Test Inspection Analysis Demonstration 





files that are contained within the system. 
KM5.1 The system shall be able to be searchable 
for all documentation contained within the 
system. 


KM5.2 The system shall be able to provide data 
files that are contained within it. Different 
levels of access shall be used depending 
on the project and classification. 


KM 5.3 Data reporting is providing the data to the 
users. The data shall include reports 
generated, letters, white papers, and 
other technical correspondence that is 
contained within the system. 

KM6.0 The system shall facilitate knowledge 
sharing. Knowledge sharing is passing 
information between individuals and 
organizations. 

KM6.1 The system shall facilitate transfer of 
knowledge between individuals. Transfer 
of knowledge shall be accomplished 
through multiple forms of communication. 
The forms of communication shall include 
written and oral. 

KM6.2 The system shall be capable of sharing 
knowledge to organizations which 
includes NAVSEA, ONR, the Fleet, and 
contractors of the Launchers Division. 

KM7.0 The system shall have the ability to meet 
the Department of Defense information 
assurance security requirements. 


KM7.1 The system shall be adapted to meet 
security requirements. The data stored 
includes Secret, Confidential, Distribution 
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KM8.0 


KM9.0 


KM10.0 
KM11.0 


KM12.0 


KM13.0 


other classified data. 


The system shall be able to adapt to new 


requirements and functionality. 


The user interfaces shall be similar to 


D, NOFORN. For Official Use Only, and 


ones that are already used such as 
common internet search engines, 


common data reporting similar to formats 


used in the Division. 
The system shall last 30 years 


The system shall have back up data 


storage, processing, and power supplies. 
The system shall be compatible with the 


Naval Marine Corps Intranet. 


The system shall be based on KM best 
practices that include a Management 


Champion, Community of Practice, 


Technology, and Processes. 


3/ 






Demonstration 


Inspection Analysis 






















The requirements were further refined as the architecture was developed 
and will be further defined when the detail system design is defined. The detail 
system will not be defined in this thesis. Table 2 was a result of the requirements 


development process. 


D. CHAPTER SUMMARY 


The derived requirements are created from the top-level requirements. 
The process of deriving the requirements includes a functional analysis. The 
functional analysis consists of generation of functions, creation of functional 
hierarchy and functional flow block diagrams. The result is more detailed 
requirements. The more detailed requirements and functional hierarchy allow for 


development of the architecture description. 
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IV. ARCHITECTURE DEVELOPMENT 


A. INTRODUCTION 


The process for the architecture description development is described in 
this chapter. It continues the systems engineering process to create the best 
architecture description when evaluated against the other concepts. The process 
consists of functional architecture development, concept generation, and 
aggregation and evaluation of concepts to satisfy the requirements. The concept 
generation process translates the requirements into concepts. The concepts are 


aggregated into a high-level architecture description and evaluated. 


The high-level architecture description created is based on Maier and 
Rechtin (2000), and the Institute of Electrical and Electronic Engineers, (2000). 
Both recommend that the description used is unique to the problem and the 
subject of the problem. The high-level architecture means integration of the 
components at the upper levels of the system (Maier & Rechtin, 2000). The 
architecture description consists of the purpose of the system, the stakeholders, 
the requirements, and architectural viewpoints. The architecture description is 
created in response to the “current stakeholder needs using current and 
estimated technological capabilities” (Institute of Electrical and Electronic 
Engineers, 2000). 


B. FUNCTIONAL ARCHITECTURE 


The functional architecture development continues the development of a 
KM system. The Figure 8 functional hierarchy and Figure 9 functional flow block 
diagram combined with an external systems diagram are the high-level functional 
architecture. This section provides an external systems diagram and functional 


viewpoints to form the functional architecture. 


The external systems diagram shows the system and the components that 
interface with the system, which is provided in Figure 10. These systems include 


the classified networks, drawing repositories, manual databases, deviation and 
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waiver tracking systems, ships’ casualty reports, other Navy knowledge sites, 
contractor repositories, and NAVSEA repositories. The external systems are 
defined as a result of the Table 1 systems matrix and the NUWC employee 
survey (results detailed in Appendix A). The findings of the situational 
assessment show that the system cannot be all-inclusive due to the scope and 
constantly changing nature of the data. The system will include processes and 


products that are within the control of the Launchers Division. 


= 
= 































Figure 10. External systems diagram 


The external systems diagram provides the interactions between the system and external 
sources of information. These sources of information are either too large or constantly 
changing to keep the information with the system. 


Each of the external systems identified in Figure 10 interact with the 


Launchers Division KM system. The CITIS and ATIS drawing repositories 
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provide drawings for multiple classes of submarines. The deviation and waiver 
tracking systems include the ELAR systems and databases that contain ships’ 
departure from specification information. There are multiple sources of 
maintenance manuals and Web-based electronic maintenance manual access 
hosted by the Submarine Maintenance Engineering Planning and Procurement 
Activity (SUBMEPP). Ships’ casualty reports are provided by SIPRNET e-mails 
and include information on system operation problems ships encounter. Other 
Navy knowledge sites include TEAMWARE, which provides a Navy-run 
collaboration system. The TEAMWARE system allows secure transfer of files 
between users including contractors and Fleet personnel. Contractors also 
maintain sites similar to TEAMWARE, and databases for storage of technical 
correspondence. The contractors who run the ships’ planning yards provide 
ships’ technical documentation that includes drawings, letters, and other types of 
technical data. The NAVSEA repositories include the NUWC Intranet and 


NAVSEA technical correspondence database. 


The Launchers Division KM system functional architecture is defined in 
Figure 8 functional hierarchy and Figure 9 functional flow block diagram. These 
figures serve as the basis for further definition of the functional architecture. The 
numbering of the functional viewpoints corresponds to the Figure 8 functional 
hierarchy, which ensures the flow down of the top-level requirements. Note the 
viewpoints that further define the functional architecture do not follow IDEF ora 
functional flow block diagram languages, because they do not support the intent 


of the architecture description. 


The Figure 11 generation of data function includes creation of data and 
transformation into useable form. It is a decomposition of function 1.0 from 
Figure 8 and Figure 9. The creation of data function shown in Figure 11 intends 
to analyze and solve Fleet operational, maintenance, and new construction 
problems. The analysis could be as simple as providing the answer to a 
previously answered problem or a material issue that is hard to solve and affects 
the safe operation of a system. Once solved, the solution to the problem is 
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archived for future use. If the problem cannot be solved easily, either a design 
solution would need to be created or research would need to be conducted to 
find a solution to the problem. The policies for creation of design solutions are 
the Launchers Divisions’ hardware development and drawing issue policies. The 
performance of research creates new solutions or creates new ways of analyzing 
a previously unsolvable problem. The drawing policy and hardware development 


policy aid in transformation of an idea into usable form. 


System Problem 
(i.e. Broken Torpedo Tube) 
































>( Creation of Sion Transformation SEMEN GHOR 
Need to be Fulfilled Project Information . 
Data into usable form > 
Question to be New Knowledge (tacit 
answered : cee _/ and explicit - 1.2 








Figure 11. Generate data 


This figure provides a viewpoint of the generation of data function. The process includes 
creation of data and transformation into usable form functions. 


The transformation into usable form function also includes additional 
processes for creation of other types of documentation. The other types of 
documentation include procedures for documentation of technical analysis and 
design decisions; this includes white papers, meeting minutes, and letters. The 
transformation of data function will allow technical analysis results to be 
documented and stored for future use. The purpose of this documentation is to 
record the details and methodology used so they can be understood and/or 


recreated to solve other similar problems. 


Input of data takes the generated data and prepares it for storage. Figure 
12 shows how data is entered into the system either by manual or automatic 
input. It is a decomposition of function 2.0 from Figure 8 and Figure 9. Manual 
input is data that cannot be directly entered into the system. It includes data that 
needs to be scanned, or is not in a format that is recognized by the system. 


Automatic data input is in a format the system recognizes, so it can be sorted for 
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data storage. Data sorting can be accomplished either by the system or 
manually by a processor or by the user. Data sorting can sort by system or 


project. 


Unformatted Data (hard 
copy data, unrecognized file 
format) 








Data Ready 


for Sorting Data Sorted 














Formatted Data 








Figure 12. Input data 


The input of data function includes data that is not electronic or in a form that cannot be 
input. It also sorts data for storage. 


Data storage and retention functions are intended to file the data until it is 
needed. Figure 13 shows the storage of the data, including divisions of files by 
system. It is a decomposition of function 3.0 from Figure 8 and Figure 9. It also 
shows classified data in a separate repository. The separate repositories include 
Naval Nuclear Propulsion Information (NNPI) and classified information up to the 
Secret level. The use of data types X, Y, and Z are to show that the database 
can be separated by system or project. For example, data type X could be used 
to store data for torpedo tubes and data type Y could store data for the Virginia 
Class Project. The development and operation of the repositories will have to 
follow DoD and NUWC policy for storage of all types of information. The 
intention is to store the data for at least 30 years, which corresponds to the life 
cycle of a ship. This means that the system will have to store the data and be 
able to read the data when some of the current software and hardware may be 
obsolete and the file format may be unable to be read. It is hard to plan for what 


is going to happen in the future and that is why the system needs to be flexible to 
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change while retaining the ability to provide the data from older file formats. 
Each file type stored may have to be evaluated as the systems change, and the 
software and associated operating systems may have to be kept to read the 


older files. 
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Figure 13. Store data 


The store data shows the parsing of data. It includes partition of classified data and 
unclassified data. The data types X, Y, and Z represent the different systems that the 
Launchers Division works on. 


Figure 14 analyzes data, which tracks system usage and analyzes the 
recurrence of launcher system problems. It is a decomposition of function 4.0 
from Figure 8 and Figure 9. The count numbers of documents’ input and output 
function is intended to determine the effectiveness of the KM system. This 
allows for determination of weak areas of the KM system operation. It also 
provides data on the usage and cost of the system to justify budgets. The other 
area of analysis is problems with launchers systems. The function is intended to 
identify systemic technical problems and understand the technical status of the 


systems under the cognizance of the Launchers Division. If the same problem 
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shows up multiple times, it could be identified as a potential systemic problem 
rather than operator error. The problem areas identified are communicated to 
the sponsors for consideration of funding to resolve the issue. These areas also 
provide lessons learned for development of future platforms, such as the Ohio 
Replacement Program. 
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Figure 14. Analyze data 


The figure includes two distinct processes. One is for monitoring KM system use and the 
other is monitoring the status of Launcher systems. 


The data reporting function is searching and providing the data to the 
system users. Figure 15 shows data search, selection, and processing of the 
data request. It is a decomposition of function 5.0 from Figure 8 and Figure 9. 
The system search will include a search capability that is familiar to the users 
such as Google or Wiki. The system will provide the candidate documents for 
selection of the needed document or database. The user selects the data and 
the system will provide the data to the user. This function primarily would be 


accomplished by system software or a filing system. 
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Figure 15. Report data 


The report data function includes searching for the data the user is looking for. Then 
selecting the information the search provides and then the system provides the 
information to the user. 


Figure 16 provides the knowledge sharing function. It is a decomposition 
of function 6.0 from Figure 8 and Figure 9. The function is based on interaction 
between individuals within the organization and outside of the organization. The 
first step in the process is the request of knowledge between employees of the 
Launchers Division or between Launchers Division employees and either the 
Fleet, NAVSEA, or contractors. The interaction can be as formal as meetings or 
as informal as phone conversations. Once the knowledge is communicated, the 
individual has to synthesize and understand the knowledge so that it can be 
applied. The interactions between the individuals are intended to reach a shared 
understanding of the issues at hand, the methodology to solve, or the solution to 


a problem. 
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Figure 16. Share knowledge 


The sharing knowledge figure provides sharing inside and outside of the organization. It 
also provides a user processing the data. 
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C. CONCEPT GENERATION 


Concepts are generated following the functional architecture development. 
The concept generation process is based on Ulrich and Eppinger (2000) and 
Buede (2009). Each of the Table 2 functions and requirements have at least one 
concept created for them. The concepts are also consistent with the functional 
architecture created, since the requirements are generated from the functional 
heirarchy. This process traces the concepts to the problem definition, and results 


in changes to the requirements. 


The concept creation process uses the morphological box technique 
described in Buede (2009). The morpological box is a process that “divides a 
problem into segments and posits several solutions for each segment” (Buede, 
2009). The list of ideas or concepts is generated using benchmarking of similar 
products, suggestions from the surveys, analogy to other systems, imagination, 
and searching related literature. The result is at least one concept for each 


requirement. 


The concepts generated are described in detail in Appendix B. The goal 
is to provide multiple concepts for each requirement, combining some of them 
into a more complex system. The concepts consist of people, processes, and 
information technology. They range from adding software to use of manual 
procedures. The software and hardware solutions include commercial-off-the- 
shelf (COTS) products. The COTS solutions range from usage of wiki software 
to usage of Google desktop, which provides a search capability. Some of the 
software solutions advertise that they have DoD software security accreditations 
that are already complete. The concepts are more detailed than the ones 
contained in a high-level architecture. Generation of detailed concepts provides 


further refinement of the problem definition and Table 2 requirements. 


The concept generation process results in changes to the requirements 
and functional hierarchy. The original system requirements did not include the 


Naval Marine Corps Intranet (NMCI). NMCI is the primary information 


47 


technology system used by the stakeholders. The requirements were changed 
to add, “the system shall function on the NMCI system.” In addition, the majority 
of NMCI users have hard key encryption, which allows the system to operate 
without the use of additional soft key logon, and the security associated with it. 
NMCI has approved hardware and software for use on NMCI systems. All other 
software has to be designed to DoD security specifications and tested to the 
security requirements by the NMCI administrator at a cost. In addition, the 
process results in revision of the functional hierarchy. The revisions remove the 


collect data function due to it being redundant with the input data function. 


D. CONCEPT EVALUATION 


The concepts from the previous section were aggregated and evaluated to 
create the recommended architecture. Concept aggregation is an iterative 
process that combines concepts and evaluates them as a whole. The evaluation 
results in selection of the high-level architecture. The evaluation ensures the 
stakeholder requirements are met by using the requirements as the evaluation 


criteria. 


Concept aggregation combines the concepts generated in the previous 
section. The combinations of hardware and software solutions include COTS 
products, existing systems, and unique software developed for the system. The 
processes and incentives are identified to facilitate system use and meet 
requirements the information technology cannot perform. The processes consist 
of ways of managing the system and generation of technical documentation, 
including calculations and correspondence. The concepts are based on a 
system that can be tailored to specific needs, including further definition of 
system capacities and functionalities. Flexibility of the high-level architecture will 


allow the system to be changed in the future. 


The evaluation of the architecture concepts consists of the use of a 
scoring matrix. The scoring matrix is based on methodology from Ulrich and 


Eppinger (2000). The scoring matrix supports the decision-making process by 
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selecting the best combination of hardware, software, procedures, and incentives 
to form the high-level architecture. The scoring matrix utilizes the requirements 
as the criteria. The requirements used are KM1.0, 2.0, 3.0, 4.0, and 5.0. The 
concepts were given values between 1 and 5 (Table 3). The standard is the 
current system: by definition, it is assigned a score of 3 for all attributes. A value 
less than 3 means the architecture concept is ranked worse than the standard. A 
value greater than 3 means the architecture concept is ranked better than the 
standard. Table 4 provides the scoring results. The top row contains the 
concepts and the column to the left contains the requirements. This differs from 
the morphological box technique by combining like themes or similar solution 
sets. In addition to the core requirements, expected development cost was 
added to the scoring matrix. This assumption is based on the American 
Productivity and Quality Center (2000) benchmarking study statement that yearly 


maintenance costs are equivalent to system start-up costs. 


Table 3. Scoring criteria 


bsTexol alate M@rai(=ar-) 





Table 4 represents the results of comparing the concepts against a 
baseline. The scores in Table 4 show that all of the concepts are equal to or 
better than the standard with respect to the requirements. All alternatives scored 
4 for all the concepts in KM1.0 and KM6.0 because they are all estimated to be 
better than the baseline by about the same amount. The alternatives scored 3 
for all the concepts in KM2.0 because they are all estimated to be the same as 
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the baseline, which may change when the systems are further defined. All 
alternatives scored either 3 or 4 for KM3.0. The alternatives with scores of 3 are 
estimated to have the same storage capability as the existing system. The 
alternatives with scores of 4 are estimated to provide additional storage capability. 
All of the alternatives for both KM4.0 and KM5.0 have scores of 4 and 5. The 
alternatives with rankings of 4 for KM4.0 and KM5.0 are estimated to have more 


functionality than the baseline. 


Cost and risk were added to Table 4 to provide additional evaluation of the 
concepts. All of the alternatives ranked lower that the baseline due to their 
additional cost and risk for development. Development of any of the alternatives 
will include additional cost. For example, development policies and procedures 
will require funding to develop them. Once developed, there is a risk that the 
stakeholders may not agree on their content or whether they are needed. 
Increased cost and risk will result from developing software. The software has to 
be coded and functional before it can be used, which takes time and money. 
There is a risk in developing the software because it may not function properly 
and or provide the functionality desired by the user. A score of 1 for both cost 
and risk was estimated for the alternative that develops procedures and creates 
software and hardware. The remaining alternatives were given a score of 2 


when compared to the baseline. 


00 


Table 4. Concept scoring matrix 
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generate data. This 
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E. RECOMMENDED ARCHITECTURE 


The alternative selected is to buy new hardware and software and 
implement procedures and incentives. It scored similar or better in all areas than 
the other concepts. The associated cost and risk of the system are worth the 
additional functionality. However, this assessment may change as funding and 


requirements are further defined for the system. 


system implementation will have to be phased to change the overall way 
knowledge is managed in the Launchers Division. The system should be 
sponsored by a senior manager and be mandatory for the employees of the 
Launchers Division. If implemented, the recommended architecture will have to 
be defined further. Part of this definition will include more detailed system 
Capability, functions, and capacities. It will also define system and software 


specific functionality. 


Fe: CHAPTER SUMMARY 


This chapter translates the requirements generated in the previous 
chapter into a recommended high-level architecture. It accomplishes this by 
generating concepts to meet each requirement followed by aggregating and 
evaluating the concepts into a system. The recommended architecture 
description is based on the top-level requirements, functional architecture, and 


the comparison of alternative concepts. 
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V. CONCLUSIONS 


A. SUMMARY AND RECOMMENDATIONS 


As a result of this study, the selected architecture description is based on 
a top down systems engineering process. The process translates the 
stakeholders’ inouts and KM best practices into the problem definition, functional 
hierarchy, and requirements. Translation of these requirements and functions 
into an architecture description provides a better way to implement a KM system, 
a better way to manage data from design to operational support, and the best 
architecture relative to the other options for knowledge management for the 


Launchers Division than the existing system. 


What is the best high-level architecture description for the technical 
KM system? The best high-level architecture is the concept that meets 
stakeholder requirements at a higher level of effectiveness within cost constraints. 
In this thesis, the alternative selected is the one consisting of new hardware and 
software combined with procedures and incentives. It scored higher across all 
evaluation criteria, which were based on the system level requirements derived 
from user needs, KM best practices, and well defined interfaces with external 
systems. The system will be more cost effective and up-to-date if it relies on 
already existing external KM systems to provide technical data due to volume of 
information, constantly changing information, and other organizations being 


tasked to manage that data. 


What is an improved way to manage technical data ranging from 
design to operational support for the Launchers Division at NUWC? This 
thesis reveals that an improved system for management of technical data 
ranging from design to operational support of the Launchers Division is based on 
multiple factors. These factors include documentation, the scope of the system, 
and changing requirements. The study reveals the types of documentation used 


are similar across the life cycle of submarine systems, allowing use of a 
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combined system. The surveys, situational assessment, and literature research 
indicate that a comprehensive technical KM system is better than the stove-piped 
KM system in place. The situational assessment reveals that a system that 
interfaces with external systems already in place is better than the standalone 
system currently in use. The creation of a single system for documentation not 
already covered by external systems would improve management of technical 


data at the Launchers Division. 


lt is recommended that the architecture developed for the Launchers 
Division be further defined in order to create a KM system. The details of the 
system need to be created and evaluated. Implementation will depend on 
available funding and consistent requirements. It is recommended that the 
architecture developed will be used as the basis for the Launchers Division KM 


system. 


B. AREAS FOR FURTHER RESEARCH 


Future study into knowledge management would include questions on 
measurement of the KM system, development of additional techniques for 
translation of tacit to explicit information, and methods of implementation and 


maintenance. 


How do you measure the performance of a KM system? It is difficult to 
measure a system that has human interfaces and is based on the needs of 
human beings that are constantly changing. Measuring cost of the system and 
organization performance are possible methods. The questions should include 
how do you measure the increase of human performance from a KM system? 


How do you measure the increase in organizational performance? 


What are successful methods of translation of tacit to explicit 
information? Nonaka (2008) uses the creation of a bread maker in his writing as 


an example of translating tacit information into explicit information. He 
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recommends the use of symbols to transfer the knowledge into explicit 
information. Further work should include creation of methodology for translation 


of information. 


What is an improved way to reduce costs to implement and maintain 
a technical KM system in an organization that supports all aspects of the 
life cycle? Implementation and maintenance of a technical knowledge 
management system are important to its own success. The American 
Productivity and Quality Center (2000) states that a successful KM system's 
maintenance costs are equivalent or greater than systems start-up costs. Future 
research would include a study into methods and cost of implementation and 


maintenance of a KM system. 
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APPENDIX A: NUWC EMPLOYEE SURVEY RESULTS 


The author generated and delivered a survey to gain a better insight into 
the stakeholders’ needs with regard to technical data generation and 
management, their current processes and procedures, and the desired 
functionality of a system to support their work. The survey and its conduct were 
approved by the Naval Postgraduate School Institutional Review Board for 
protection of the people surveyed. The people surveyed include Launchers 
Division management, Launchers Division engineers, selected customers, and 


contractors. The responses are documented in Table 5. 


The survey was generated to focus on the Launchers Division KM system. 
The questions were written to understand how individuals generate data on, 
understand the processes and procedures in place, the barriers to knowledge 
management and provide insight into the functionality of the stakeholder's ideal 
system. The following is the questionnaire that was provided to the stakeholders. 


The survey questions and results are shown in Table 5. 


Questionnaire 

The purpose of this questionnaire is to gather information to create an 
architecture and implementation plan for a VIRGINIA Class Launchers KM 
system database. This database will support VIRGINIA Class tasking and may 
evolve into supporting other classes as well. It is intended to support daily work, 
track system issues (recurring events, etc.), document lessons learned from 


design to operation, and provide an external reporting system. 


O/ 


Table 5. Raw survey results 


What are your current problems with technical data availability in your everyday tasking? 
“What specific aspects of the current situation are unacceptable? 


The Launchers Division has no central paper nor digital repository of data, classified 
nor unclassified. Prior management positions was that files are kept at the TPM 
level. In current reality, personnel (including TPMs) move often and not all are/nave 
been as knowledgeable/diligent at repository of information. 


As an organization we do not have a repository of ready-access data from which to 
make educated decisions about the health and performance of systems under our 
cognizance. For example, recurring or systemic technical problems are handled on a 
reactive basis as they are discovered. Farming data for emerging trends Is not 
possible at this time. 


Additionally NUWC’s responses are never officially recorded. Most activities have a 
way they document problems they are fixing (i.e., ERs, LARs, etc). NUWC receives 
phone calls and e-mails and responds the same way. 


Lack of a system to store new data as it is created. The majority of information 
systems available to us are not user friendly if not used on a frequent basis. 


Data usually exists in someone's desktop files but must be reacquired by each 
individual on an as needed basis. 


Handling complications required because documents are unnecessarily entered into 
the U-NNPI(Unclassified Naval Nuclear Propulsion Information) network. 


Current technical data bases are mostly from experience level. The senior 
engineers/Technicians have the experience in various areas but it is not documented 
in any overall database. What is unacceptable is that the passing of knowledge is 
almost at the “tribal” level. The junior people will learn if the senior personnel are 
outgoing and interested in passing down knowledge. If not, the knowledge is lost. 
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Conclusion Based on the responses, there is no central repository for data. There is no way of 
transfer of tacit knowledge to explicit knowledge to train new employees. There is no 
official way of recording data or one mandated. There is no way to understand 
emerging trends on existing equipment. 


Do you have a system in place? If so, what are the strengths and weaknesses of the system. 
This can include your own or the organization’s knowledge management system. 


There is no comprehensive system in place. There are individual systems in place, 
most of them brute-force manual systems. 

There are difficulties managing data with different classification levels. 

The three-inch launcher and Trash Disposal Unit (TDU) In Service Engineering Agent 
(ISEA) has a paper data base consisting of documents generated since around 1980. 
The System Manager has about 8 four tier unclassified lockers in his office. Each 
locker has numbered folders with common information is each folder. A Microsoft 
Word file has the listing of each locker folder and the title of each separate document 
in each folder. One has to use the search program to find the locker and folder for the 
wanted information. The strength of this system is that information on recurring and 
unique system problem areas is readily at hand and has proven to greatly successful 
for everyday problem solving. The weakness of the program is locker space to 
Support ever growing data input and that the folders/locker contains superfluous 
information that never has been thoroughly reviewed. 


Conclusion There is no comprehensive system in place. There are individual systems in place 
and data needs to be managed at different classification levels. A comprehensive 
system of managing data is needed. 

What part of the current system works well? What does not work? 


The disaggregation of our existing systems do not work well. The manual nature of 
our existing systems do not work well. 


The collection and implementation process does not work well. In fact, having 
multiple systems without a clear direction on their use causes them to act as black 
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holes. 


Holding individual copies of information works well. However it is not available to 
others. 
The best systems are user friendly. 
The system is detail oriented and provides great background on recurring problems. 
The locker area is finite. The creation of folders is labor intensive. Proposed scanning 
of existing and new files is expensive. 
Individual systems work well. Some have great detail. 
Conclusion No central system exists. There is a good example of an existing system. The 

system varies by person and program. The KM system needs to be user friendly. 

What functions do you need for knowledge management in your tasking? A function is a task 

the system performs. 

Document management (internally generated or received from external) 
Digital repository with paper capability (for classified or sensitive data) 
Ease of deposit of documents, simplicity of addition of indicative data for each 
document 
Title, keywords, author/division POC, date, other doc numbers, external organization, 
funding project, etc (perhaps metadata in a future state) 
Flexible reporting of the KM system (allowing management to pull various statistical 
information, how many deposits, deposits bound by dates, deposits with no files 
attached, etc...) 
Robustness of SEARCHING for data (advanced queries, indexing of title, keywords, 
etc on all indicative data 
Serve as a historical archive, where ongoing and future engineering efforts can 
understand and incorporate lessons learned in the past. 
Allow external sources, such as supporting contractors and program sponsors to 
monitor health and performance of the systems in near real-time, 
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Allow data farming to identify trends in order to move our work to a more proactive 
posture. 

Conclusion The primary functions requested include management of documents, provides 
means of analysis, allows access from external organizations, and supporting several 
different ways to search for information in the archives., 

When looking for Technical Letters what process do you use to find these? 
| can never find the letters unless | wrote them or reviewed them. 

Ask the secretary OR a TPM OR someone that was involved in the project. Hit or 
miss. 
In some cases we have to ask external sources that we sent the letter to. 
CITIS but it is sparsely used 
Conclusion There is no formal process or repository for storage of technical correspondence. 
When looking for drawings or manuals what process do you use to find these? 
ATIS, CITIS, or ask another person in the department. 
Not certain what process exists for pulling Manuals 
Naval Sea Logistics Center which is required to keep and maintain all ship logistics. 
Drawings, depends on submarine Class. 688, 726 and 21 are available via ATIS; 
7/74 via CITIS. The drawings for the particular equipment | am responsible for are not 
available on ATIS. | keep them on my hard drive. If the drawings are not available 
via ATIS or CITIS, you can try DAPS. 


Tech Manuals are available online at TDMIS, but it’s not very user friendly. 
Maintenance Manuals, Ship Systems Manuals including Ol’s, Naval Ship Technical 
Manuals, are available on our Department Public Drive. ODs you go to Eric Von 
Tish, who maintains the ODs. The library has some tech manuals, and has an online 
catalog that is searchable. 


Conclusion Drawings and Manuals are provided by external organizations primarily through two 
databases: CITIS and ATIS. This function should remain in the cognizant 
organization due to the cost of maintaining an up to date database. 
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When looking for Fleet identified problems what process do you use to find them? 
| am not aware of a comprehensive database that stores Fleet identified problems. 
The Remedy system that was developed to track Fleet problems and resolutions was 
terrible and was never used. We tried to develop a Remedy-lite system in our branch 
but because it requires additional (redundant) work to enter information, it is seldom 
used. 


Equipment problems that are reported by in-service submarines are usually reported 
as requests for deviations or waivers. There is an E-DFS site, but it is not user- 
friendly. 


Locally received and approved deviations and waivers, applying to work being 
performed under contract to NUWC, we keep in a database developed within the 
Division. But it is only a few years old and doesnt contain a lot of data. 


Fleet identified problems are reported by deployed submarines via Naval Message. 

(A couple years back they decided to include SUBS in the subject line of these 
messages to make them easier to discern and track. There is no database that | am 
aware of that stores Naval Messages beyond 30 days after issue. Similar to technical 
letters, Naval Messages will only be available if of critical importance. Naval 
Messages are most likely to be found with the author / originator. 


Ask an ISEA(in-service engineering agent) expert from that system area. 
Review highlights database 

| wait for notification from them via naval message. This has not been an effective 
method of communication between us as designer and them as end-user. They do 
not have robust systems on their end so entry of issues at the source is not always 
occurring. 
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Conclusion There is no comprehensive database to collect launcher related data. In addition, 
not all problems are reported on the user’s end. One thing that did not come out in 
the surveys is that the Fleet uses a higher classification system to send naval 
messages. The Launchers Division primarily works on a lower classification network. 


If you are looking for the configuration of a system on a certain ship, what is the process you 
use to find it? i.e., | am looking for an all the engineering reports for the torpedo tubes how 
would I find them? 


ATIS contains some ships configuration data, but is thought out of date. Ship checks 
are usually required. Or a phone call to Fleet personnel, or others that may be 
“expert” in that system. 


Conduct a ship check, as | would not believe that configuration management at that 
level would be reliable. 
The tech homepage (which is described in the Table 2). 


Conclusion This ts a similar question to finding drawings, since the drawings contain the majority 
of the configuration. The ships drawings are large in multitude and would be hard to 
maintain them up to date. Ships drawings are the responsibility of the planning 
yards. 


When looking for calculations what process do you use to find them? 


To the best of my knowledge, only SSDR calculations are stored. | contact the 
Planning Yard for the particular submarine class via LAR, and request a copy. 


Going to the cognizant engineer or technical program manager. 


Official Calculations are stored at the library but there are very few that are made 
official. 


In local directories 
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Conclusion 


In most cases, you just do a new calculation. Where you know a particular 
calculation has been required repeatedly, and will be needed for reference in the 
future, it is best to document such an analysis or calculation ina TM. These are 
stored in the NUWC library once published. 


A process for storing calculations is needed. Means of generation and a standard 
format including a system to ensure that they are searchable is needed. 


When looking for technical specifications what process do you use to find these? 


Conclusion 


When looking for design decisions, what process do you use to look for them? What process 


Contact Electric Boat or Newport News Shipbuilding and issue Liaison Action 
Request perhaps, if ATIS does not possess (which it would not for tech specs) 
Classified Data repository for Shipbuilding Specifications. 

Internally for specific equipment specifications. 

Information Handling Services is the best place to find up to date specifications. 
Storage of technical specifications is outside the scope of the thesis. Only specific 
specifications are kept up to date within the department. Commercial specifications 
are available via the NUWC Library and would be too hard to keep up to date since 
there is a large number of them and are continuously updated. 


do you use to document them? 


| would look for drawing Engineering Change Proposal’s and Technical Variance 
Documents. 
CITIS for Engineering Reports 


Unfortunately there is not a division wide repository for such information. Within my 


own office or position, the files of all predecessors have been digitally scanned, but 
no front end or interface is available. They are on a disk. 


There is no official process to document them. 
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Conclusion 


There is no official process to document design decisions made by the Launchers 
Division. 


What is the most important data required to conduct your tasking? 


Conclusion 


My personal digital files. 

End-user feedback of issues discovered during operation, (i.e., Fleet input). 
Anything that answers the question: how did we get here? That would include 
background information on the tasking in question, which is usually documented 
formally in test plan/report front matter, and in the background paragraphs on letters 
to/from NAVSEA. 


All of the data you have mentioned above: drawings, configuration of a particular 
ship, deviations and waivers, calculations, tech manuals, test results. In addition, 
LARs, procurement history (list of previous suppliers, in particular). 

Materials information, detailed requirements documentation, and vendor data. 


Technical documentation needs to be stored. All relevant design data is important 
including drawings, calculations, and technical manuals. 


What is the least important data required to conduct your tasking? 


Conclusion 


| don’t Know the entirety of the data | work with 

Extraneous “chatter” in emails, frequently surrounding those 1-2 sentences of 
information that | actually need. (A more efficient keyword search in Outlook would 
be nice.) 


Old contracts 


Irrelevant, usually e-mails from other people who are answering commitments that 


have no relevance to what | am doing. 


This question had some responses and could have been accomplished in a different 
manner. Overall it is important to document most technical data. 


When looking for test results (at sea, DT and OT) what process do you use to obtain these? 


Ask those who were likely to have participated in these events in the past. 
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Go to Code 25 folks, but unfortunately their objectives center on testing Non 
Propulsion Electronic System functionality and they often record issues with my 
system as an afterthought. If our folks participated in the test, | may be able to review 
their trip reports. Unfortunately, it is not mandatory to fill out a trip report and most 
that | have gotten were due to my nagging, not their management's. 


Test results are usually documented in the test/trip reports, which are usually found 

as enclosures —or at least references— to NAVSEA letters. Raw data is usually 
archived on CDROMs/DVDs or network servers, and can usually be found via the 
dates, test facilities, and SMEs named in the applicable reports. 


For in-service submarines, | believe SUBMEPP maintains copies of completed test 
forms. | contact my SUBMEPP POC and ask. If the maintenance activities have 
forwarded the results, SUBMEPP will have them. For Maintenance Requirement 
(MR) cards other than K-type, go to the local Intermediate Level Maintenance Activity. 


For new construction submarines, | believe the Shipbuilders maintain copies of 
completed test forms. For results of K-type MR cards, go to the local Performance 
Monitoring Team. (Inexplicably, data from K-type MR cards Is not made available to 
ISEAs for evaluation.) 


Go to the Code 25 contractor run deviation tracking system that has all of the test 
findings 

Conclusion Test results from equipment tested ashore are easier to find than at sea system 
testing. At sea system test data is important to understand the strong and weak 
areas of the systems. Understanding this allows for improvement of the current and 
development of future designs. 

Would a knowledge management system tool be useful in conduct of your work? 


Any organized, comprehensive, searchable DOCUMENT MANAGEMENT system 
would be hugely beneficial. 
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I'd say that it is critical and in fact we are not doing our job effectively without out. 


Conclusion 


The submarine community is wasteful at this point in time, working issues over and 
over again without even knowing it. 


A knowledge management system is important for conduct of work and will be useful 


to the Launchers Division. 


Do you know of instances where technical data is unavailable that you need. If so what are 
they? How can this problem be solved? 


This happens each and every day here. There are no central repositories (within 


Conclusion 


Code 412 at least!) to store and disseminate data. Our technical library has not 
embraced this, not sure why. Other organizations are moving towards efficient 
enterprise wide solutions, and we are still relying on manual based processes, or 
simply “people”. Which is great until those people go away. 


Being redundant, but we NEED a centralized solution for document repository. It 
needs to be simple to upload the document along with any indicative data, and needs 
to have robust search capabilities. 


A good example would be sea trial results, which are currently classified at a level | 


can't access simply because it was conducted by a test group that is accustomed to 
working with data also collected during the test that | don’t even need. 


For a current project we are looking for design performance data of a particular piece 


of equipment in order to assist with computer modeling. The information that we 
require does not appear to be available. Our options are to keep looking, or try to 
recreate the data empirically. 


| don't have access to a database that quantifies the failures in my area. There is a 


“3M” system but | don't have a way of getting to it. Establish a link to it for NUWC, 
Code 40. 


Yes, there have been several times that | needed 688 class SSDRs and NUWC did 


not have them.. | had to get them from the 688 Class PY. 


There are many instances of missing technical data. 
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If you were going to create the system, what functions would it perform and how would it be set 
up? 


See functions above 


lt would be accessible and easy to use. Something simple and elegant is required. 
Too many of the competing systems have a “whiz-bang’” feel reflecting a 
programmer's interests and not those of the actual users. It would be universal, 
meaning that all relevant participants of this diverse technical community would see it 
as the sole repository, as such it would become comprehensive. _ It would be 
mandatory because we unfortunately are working in an atmosphere of complacency 
and entitlement. 


lt would be available online, accessible from anywhere. It would be a comprehensive 
system, containing drawings, deviations, manuals, etc all in one system or at least 
through a common portal or interface. It would be readily searchable by keywords, 
dates, author, etc. It would be continuously updated without any additional work on 
the part of the user. It would be maintained by dedicated personnel who are skilled in 
archiving. It would be a system that could be relied on to still be in existence and 
available 5, 10 or 15 years down the road. 


Prior to NMCI, many of us had Google Desktop installed on our computers. This was 
a great tool to search through all your files, emails, etc. at once. 


Backed up regularly for access should the network become unavailable for a period 
of time. 


Conclusion The functions are defined in the question above and in a previous question. 


What type of data are you looking to store? And, how long do you need to keep it? And, what 
are the known relationships between those pieces of data? 


Need to store outgoing responses to shipyards, research about problems for future 
use, test reports etc... 
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Conclusion 


Types — ALL types. Any “product” that we create. | define a product as any 
document that we send out to a stakeholder (white paper, presentation, letter), or that 
we use internally to perform our work (test plan, test report, controlled work package, 
calculation package, etc). 


How long to Keep? Forever 
Unknown 


For example, shock qualification data should probably be stored as long as the 
subject system Is deployed, i.e., forever (effectively). Available historical data should 
facilitate reverse-engineering any system, by anyone with relevant technical 
knowledge/expertise and need-to-know. 


Data needs to be stored for the life of the particular submarine or submarine class. 


Typically, 30 years or so. 


Ongoing and historical type data. | don’t know. | Know ours works but it would be very 


Cumbersome on a Fleet wide level. 


All types of technical data. The size stored will depend on the system defined. The 
system has to store data for at least thirty years. 
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KM1.0 


KM1.1 


KM1.2 


KM1.2 


APPENDIX B: SYSTEM CONCEPTS 


System shall be able to generate data. 
Generation of data includes facilitation of the 
Figure 6 knowledge cycle. This includes 
standard templates for generation of letters, 
calculations, and drawings. 


The system shall be able to create data. This 
includes standard templates for generation of 
letters, calculations, and drawings. 


System shall be able to assist in translation of 
tacit to explicit data. This shall include 
shadowing of experts to understand how the 
task is completed. Followed by translation of 
the tacit knowledge (understanding0O into a form 
that can be used by others. Other methods can 
be used to accomplish this task. 


System shall create incentive for users to 
create and share knowledge 
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Automatic Templates for technical documentation. 


Create standard procedures developed by the department to 
create technical documentation including: calculations, test 
reports, letters, drawings and other technical documentation. 
Create department policy with a person that is in charge of 
standardization of technical documentation. 


Voice Recognition software to capture meeting minutes, write 
letters, and create other documentation. 

Procedures for standardization of documentation. 
Requirement for documentation in certain cases. 

This can be done in second increment 

Translation trade by one group into documentation. 
Translation of design methodology into details using diagrams 
and instructions. 

Training on how to do this 

Requirements for personnel to accomplish this. 


Put it in Performance Review which directly affects raises, NUWC 


is under a pay for performance system. 
Have a bonus for personnel contribute to the overall system. 
End of year award for this. 


KM2.0 


KM2.1 


KM2.2 


KM3.0 


KMS3.1 


The system shall be able to assist in translation 
of tacit to explicit data. This shall include 
shadowing of experts to understand how the 
task is completed. Followed by translation of 
the tacit knowledge by changing it into a form 
that can be used by others. Other methods can 
be used to accomplish this task. 


The data shall be able to be entered by all 
users. Users include Launchers Division 
personnel, NAVSEA headquarters employees, 
and Fleet Personnel with access to NMCI. 


The system shall have the ability to sort data by 
system and project. Systems include torpedo 
tube, weapon shipping and handling, internal 
countermeasure launcher, external and internal 
countermeasure launchers, trash disposal unit, 
surface vessel torpedo tubes, weapon shipping 
and handling, and vertical launch systems. The 
system shall include the ability to sort data by 
project. 


The system shall provide the ability to store 
data. 


The system shall store technical 
documentation. Technical documentation 
includes letters, calculations, liaison action 
requests, drawings and can be expanded to 
other documents. 
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Upload it electronically into system 
Place it in paper repository 


Easy to use computer interface. 


Paper insertion into the files. 
Automatic input by email or other means. 


Users have to designate what system using a check box 


The system searches for keywords and places it in the right file. 
System operation on an accessible network with hard drives and 


software to support tt. 
File Cabinets with workers to provide them when needed. 


Electronic Repository to store the documentation. 





KM3.2 


KM4.0 


KM4.1 


KM4.2 


KM5.0 


KM5.1 


The data storage capability shall be expandable Additional hardware can be hooked into the system. 
to meet the needs of the division. 
Data partitions in paper file 
The system shall provide the ability to analyze See sub requirements 
data. Analysis includes input and output 
metrics. Analysis includes identification of 
system issues (the second part can be a follow 
on capability) 
The system shall be able to analyze launcher Manual search for similar problems by launchers personnel. 
system data. This function shall be performed Statistics generated for failure rates and operational availability. 
by launchers personnel or a software program. 


The system shall provide input and output Software to measure system usage. This includes areas they are 
metrics. This is the number and size of used. There is commercially available software for this 
documents handled by this system. application 


For paper repository the files can be tracked manually 


The system shall provide the ability to report 
data. This includes providing data files that are 
contained within the system. 


The system shall be able to be searchable for 
all documentation contained within the system. 


Google search 
Wiki type interface 
| wish it could be automatically sent to the user. 
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KM5.2 


KM 5.3 


KM6.0 


KM6.1 


KM6.2 


KM7.0 


The system shall be able to provide data files 
that are contained within it. Different levels of 
access shall be used depending on the project 
and classification. 


Data reporting is providing the data to the 
users. The data shall include reports 
generated, letters, white papers, and other 
technical correspondence that is contained 
within the system. 


The system shall facilitate Knowledge sharing. 
Knowledge sharing is passing information 
between individuals and organizations. 


The system shall facilitate transfer of 
knowledge between individuals. Transfer of 
knowledge shall be accomplished through 
multiple forms of communication. The forms of 
communication shall include written and oral. 


The system shall be capable of sharing 
knowledge to organizations which includes 
NAVSEA, ONR, the Fleet, and contractors of 
the Launchers Division. 


The system shall have the ability to meet the 
Department of Defense information assurance 
security requirements. 
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by email files. 


| wish it could be direct access. 
Software access 


Network access 


Use current ipt structure and force additional individuals to 
participate. 


Change environment through cultural change. 


Representatives could be sent to Fleet post deployment, similar to 


TOMIS system. 


Technical documentation to be sent to Fleet. 
Fleet representatives should be part of program reviews. 





KM8.0 


KM9.0 


KM10.0 


KM11.0 


oo kmi2.0 


KM13.0 


The system shall be able to adapt to new 
requirements and functionality. 


The user interfaces shall be similar to ones that 
are already used such as common internet 
search engines, common data reporting similar 
to formats used in the Division. 


The system shall last 30 years 


The system shall have back up data storage, 
processing, and power supplies. 


The system shall be compatible with the Naval 
Marine Corps Intranet. 


The system shall be based on KM best 
practices including Management Champion, 
Community of Practice, Technology, and 
Processes. 
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Operating system has the ability to add software and files be able 
to interact with the software. 


Use Upload Buttons. 
Use up to date search tools. These include Google, wiki, Bing 


search engine and tools that are familiar to people. Google has 
NMCI capable software. 


Data presentenced in a read able manner. 
Security system partitioned off the system. 
Use standard file formats, word, pdf that will be able to be read for 


a while. 


System could maintain older software to pull up the file formats 
needed. 


Back up hard drives that save material 


Dual backups 


Back up operating system. 
Use TOMIS for data storage. The engineers have the experience 


to complete this type of tasking. 


Design and Test software to comply with NMCI rules. 


Combinations of technologies. Incentives, and processes. 
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